Currently implemented communication systems for mobile devices allow users to easily access data services in addition to the traditional telephony services. Commonly used data services include email and web browsing. These existing data services rely on the mobile device acting as client, with data being requested (either directly or by subscription to a relevant service) and subsequently pushed to the mobile device from a network server (based for example in the network operator's domain or in the wider Internet).
Machine-to-machine (m2m) refers to the exchange of information between devices substantially without the need for human intervention. Such communication may be facilitated by the data services offered by existing mobile communication networks. By way of an example, a domestic electricity meter may be coupled to a mobile device (with SIM card installed) in order to periodically send electricity meter readings to a central server of an electricity supply company, via a mobile communication network to which the mobile device has access. Such services work well where it is the device which initiates the communication. It may be difficult however to implement services which require the central server (or other remote point) to initiate the communication. Considering again the above example, this scenario might arise when a user detects a fault with his or her meter and reports this to the supply company, whereupon the supply company wishes to poll the user's home electricity meter to obtain various data therefrom.
In today's Internet, IPv4 address space is severely limited given that an IPv4 address is composed of 32 bits. Despite the standardisation of IPv6 with a much greater address space, legacy issues (particularly associated with Internet routers) mean that IPv4 remains dominant. Mobile network operators must therefore live with the constraints of IPv4. In particular, operators have had to find a way to allow the many millions of mobile users to access IP data services despite the fact that the operators themselves are allocated only a relatively small number of unique IPv4 addresses. This is generally achieved using a process known as Network Address Translation, whereby the mobile devices are located behind a Network Address Translator (NAT). Within the operator's domain, private IP addresses are used to identify connected mobile devices. These private IP addresses are unique only within the operator's domain. The NAT allocates external IP addresses and ports (from a pool of available addresses and ports) as and when required by mobile devices. Using 3GPP terminology, this IP address allocation will likely occur at Packet Data Protocol (PDP) context creation. Typically, multiple mobile devices will share a single external IP address. A mobile device will randomly select a so-called “ephemeral” port number from a range of available port numbers. This ephemeral port number is included as the source port number in outgoing packets for the mobile node, and as the destination port number in incoming packets destined for that mobile node. The NAT maintains a mapping between external IP addresses and port numbers on the one hand and private IP addresses and port numbers on the other. The NAT performs IP address and port number translation for incoming packets using this mapping. IP address and port number translation is also performed by the NAT for outgoing packets based upon this mapping.
A problem with NATing is that, as a mobile device does not have a permanently allocated external IP address and port number, it is generally not possible for an external device to initiate a communication session with the mobile device. The external IP address and port number mapped to a particular mobile node may even change between different PDP context creations. The NAT must reject all such externally initiated communications to avoid the risk of them being forwarded to the wrong mobile device. In some cases it may be possible for a mobile device to initiate and establish a connection with an intermediary server via the NAT, and to maintain that connection by regularly polling the server. An external peer device may then initiate a connection with the mobile device by routing a connection request via the intermediary node and through the already open “pinhole” in the NAT. This of course requires that an appropriate application be installed in the mobile device (and in the external peer device), and that signalling be exchanged between the mobile device and the intermediary server hosting the registration service each time the device is allocated a new external IP address and port number (in addition to the polling traffic).
US2010/0094978 describes a mechanism for interfacing a private network to a public network such as the Internet. This involves providing a node or nodes in the public network with a host identifier having a first part identifying a server agent interfacing the two networks and a second part identifying a server present in the local network. Using the first part of the host identifier, a node in the public network is able to obtain an IP address for the server agent (e.g. using a DNS lookup) and open a TCP connection to the server agent. The public network node then forwards a message, destined for the private network server, to the server agent. This message includes in it the relevant host identifier. The server agent listens to a well known port, e.g. 80, and receives connection requests on that port. The server agent uses the second part of the host identifier to forward the received message to the private network server. This approach is limited to those protocols such as HTTP which allow the hostname to be included within the message sent from the public network node to the private network server. It is not applicable to protocols that do not allow this such as SNMP, SSH, SMTP, LDAP as well as other proprietary protocols that run over IP.
The problems presented by approaches such as US2010/0094978 are addressed by WO2012/103938 which proposes allocating a private network IP address, a hostname (e.g. imsi_x.oper.com) and a service name (e.g. service_x_.tcp.imsi_x.oper.com) to a first node (e.g. being a mobile terminal associated with a particular International Mobile Subscriber Identity, IMSI) within a private network, the service name being associated with a service provided by the first node. At a gateway interconnecting the private network with a public IP network, a unique public network side port number is allocated to the first node. A mapping between the private network IP address (and optionally the private network side port number) and the public network side port is included in a connection table. The following records are installed in a Domain Name System, DNS, of the public IP network:                a service, SRV, record defining the service name, hostname and public network side port number as the location for the service name, and        an address, A, record defining a public IP address of the gateway as the location for the hostname.        
A second node or “application”, attached to the public network but outside of the private network, is thereafter able to perform a DNS lookup in the public IP network in order to resolve the service name into a public IP address and port number. The gateway listens at the public side network port number for connection attempts to the first node, performs address and port translation on incoming requests using the mapping, and forwards the requests to the first node.
FIG. 1 illustrates schematically the approach described in WO2012/103938 and which involves the introduction of a new node defined as an Mobile Device Service Internetifier (MDSI). The MDSI uses information provided by the GGSN that is triggered by a PDP context creation. The information is sent using the Radius protocol and includes inter alia the MSISDN, IMSI, IMEI and the assigned private IP-address of the mobile server. Furthermore, the MDSI uses information that has been pre-provisioned in it, including the service(s) name and local port(s) that is provided by the mobile device.
In summary, WO2012/103938 enables two-way communication between a (m2m) device located in internal network and an application located in an external network. Any request received by the gateway from an external application will be forwarded automatically to the device, i.e. transparently, using the private IP address and private port number via port mapping in the gateway. This gateway is transparent and able to forward any two-way communication traffic in any protocol based on TCP/UDP between the external application and the internal device.
The approach described in WO2012/103938 does not, by itself, allow an external application to explicitly address and access multiple service instances (i.e. resources) with the same service protocol name on the device, e.g. the external application cannot directly access multiple HTTP or CoAP service instances (resources) that are defined on different resource URI paths with the same service protocol (HTTP/CoAP) and service port number, and with the same IP address (same device).
Consider for example a logistics company operating a fleet of delivery trucks. Each truck may be provided with an m2m device that is attached to a Public Land Mobile Network PLMN. The PLMN performs NATing on upstream and downstream packet traffic to allow a large number of m2m devices to share a relatively small pool of public IP addresses. Each truck is further provided with a number of sensors (“resources”), e.g. including a container temperature sensor, camera, etc. These resources are coupled to the m2m device, for example via a local WiFi network or using Bluetooth™. Via an application provided at the control centre of the logistics company, the company wishes to obtain data from each of the resources across its fleet of trucks.
WO2012/103938 provides only for direct addressing of m2m devices via service protocol, IP address, and port number. Such addressing, via a unique DNS registered device hostname (for example based on the m2m device's IMSI and which links the SRV records to the A records) is a coarse and inconvenient method and in particular does not allow developers of m2m applications to distinguish between different APIs exposed by the device. Furthermore, the mapping provided by the prior art approach limits both the amount of services that can be exposed behind a given public IP address (to the total number of ports—65535) and the flexibility with which new services can be introduced (due to the need for manual configuration of the mapping). An m2m device may act as an aggregator of multiple resources which are identified by different resource URIs and need to be addressed and accessed individually by an application. The mechanisms presented in WO2012/103938 require the application to know everything about the device and the resources exposed by it, e.g. what is the correct resource URI path on the device to address and access, and the application must use exactly the same service protocol and request format as the device uses in order for the device to understand and parse the request correctly. Commonly used applications do not know so much about the device or the services they access.